Performance Evaluation of Multicast for Small Conferences

Many new Internet applications require data transmission from a sender to multiple receivers. Unfortunately, the IP Multicast technology used today suffers from scalability problems, especially when used for small and sparse groups. Multicast for Small Conferences aims at providing more efficient support for example to audio conferences. In this work, we present a performance study of the concept, based on simulations of real-world scenarios with the ns-2 network simulation software. The results indicate that Multicast for Small Conferences has the potential of replacing IP Multicast for many delay sensitive small group applications, even with very limited support from the network infrastructure. 1 Explicit Multicast IP Multicast does not scale well for (many) small groups such as in audio conferences or multi-player games. Multicast routing entries cannot be aggregated such as unicast routing entries since multicast address selection is arbitrary. Moreover, multicast routing entries do not only consist of destination addresss but may include source addresses. With many small group applications routing table sizes are increasing massively, which deteriorates the performance of (backbone) routers. Explicit Multicast [3] (Xcast, the successor of Small Group Multicast [4]) is a multicast scheme designed for supporting a very large number of multicast sessions as present in audio/video conferencing, network games or collaborative working. It differs from native multicast in that the sending node keeps track of all session members and explicitly encodes the list of destinations in a special packet header. This newly defined header introduces a new protocol between the network (IP) and the transport (UDP/TCP) layer. Xcast capable routers that receive such a packet parse the Xcast header and use the ordinary unicast routing table to determine how to route the packet to each destination, generating a packet copy for every affected outgoing interface. Each address list contains only the addresses that can be reached via that interface. If there is only one destination address for a particular next hop, the packet may be sent as a standard unicast packet. With the Xcast scheme, routers do not have to maintain per session state. This makes Xcast very scalable in terms of the number of sessions that can be supported. Also, no multicast addresses are used, which eliminates all problems related to multicast address allocation. Another advantage is the fact that no multicast routing protocols are required, neither intra nor inter domain. Xcast packets always take the correct path as determined by the unicast routing protocols. 2 Multicast for Small Conferences Like XCase, the Multicast for Small Conferences (MSC) [5] concept aims at solving the scalability problem of native multicast by explicitly carrying all destination addresses in the data packets while at the same time avoiding the problems of Xcast. In contrast to Xcast, MSC defines mechanisms to integrate native multicast and Xcast concepts [5]. These are beyond the scope of this paper. The basic MSC packet forwarding mechanism is identical to Xcast. However, instead of introducing a new protocol, MSC relies solely on the existing IPv6 protocol, in particular on the IPv6 routing header. A sender will create a unicast address list of all group members and put the nearest one in the IPv6 destination address. All other member addresses are stored in the MSC routing header, preferably ordered by the distance from the sender (in hops). The group’s multicast address should ideally be stored in the routing header as well. If members have to be reached via different outgoing interfaces, a packet for each affected interface is generated with the list of members that can be reached via this interface. This means that the sender divides the address list into N parts and sends N copies of the packet to the N generated lists. A receiving end system which finds its address in the header creates a packet for the higher protocols encapsulated in the IPv6 packet by copying the multicast address into the IPv6 destination address and removing the routing header. An MSC gateway forwards the packet to local multicast receivers using the appropriate scope. If the routing header contains further unicast addresses, a new packet is generated with the address of the nearest node in the IPv6 destination address. As before, a routing header carries the remaining unicast addresses. A router that does not understand the MSC header forwards the packet towards the address specified in the IPv6 destination field. This also means that no tunneling between MSC gateways is necessary, which simplifies a gradual deployment. MSC capable routers read the addresses from the destination field and the routing header and determine the outgoing interface for each destination. They then duplicate the packet for each involved link. Again, each packet contains only the unicast addresses that can be reached via that interface plus the multicast address identifying the group. In this document, this router behavior is denoted standard MSC. A possible improvement of the basic MSC concept involves the use of topology information, which can for example be obtained from a link state routing protocol such as OSPF. The first MSC router that handles an MSC packet after it enters a certain network domain (e.g. a backbone network) determines the egress router (i.e. the router where the packet leaves the domain) for the destination address and all addresses listed in the routing header. A packet is then created for each involved egress router. Thus, packet forwarding between destinations connected to the same network can be eliminated, which potentially reduces the delays. On the downside, multiple packets may be sent over the same link, if two or more egress routers are reached via the same outgoing interface. In this document, this advanced concept is denoted enhanced MSC (EMSC).